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L'invention concerne la gestion de priorites d'acces par des 
applications & des ressources dans un reseau de communication 
domestique, ainsi qu'un appareil pour la mise en oeuvre du proced6. 

5 

Dans un reseau domestique, un certain nombre d'appareils sont 
relies par uh reseau de communication et communiquent par I'intermediaire 
d'un langage commun. De tels reseaux evoluent vers la transmission de 
donnees audio et vid6o, et peuvent par exemple etre bases sur un bus 

10 s6rie de type IEEE 1394. Les appareils connects au reseau peuvent 
posseder des 'ressources 1 , c'est d dire des fonctionnalitgs particulidres. Un 
televiseur poss&de par exemple un tuner, un ecran cathodique, tandis 
qu'un magnetoscope possede un tuner et une fonctionnalite 
d'enregistrement. Les ressources d'un appareil pouvant etre mises a la 

15 disposition des autres appareils du reseau (par exemple un magnetoscope 
effectue I'enregistrement d'une Emission en controlant le tuner du 
televiseur), des conflits d'acc&s aux ressources peuvent apparattre, une 
ressource pouvant recevoir des commandes contradictoires de la part de 
diverses applications. 

20 L'invention a pour but de proposer une gestion des priorites 

d'acces. 

L'invention a pour objet un procede de gestion de priorites 
d'acces d'applications a des ressources d'appareils connects par un 
reseau de communication, caract£rise en ce que ledit proc6de comporte les 
25 etapes : 

- d'attribution d'un niveau primaire de droits d'acces a une 
application effectuant la reservation d'une ressource, 

- d'attribution d'un niveau secondaire de droits d'acc&s a 
d'autres applications effectuant une reservation de ladite ressource, les 

30 droits d'acces du niveau secondaire etant tels qu'ils n'interferent pas avec 

les droits d'acces du niveau primaire. 

Selon un mode de realisation particulier, une ressource admet 

simultanement des reservations par au moins N applications, avec N 

sup£rieur ou egal a 1 . 
35 Selon un mode de realisation particulier, une application 

effectuant une tentative de reservation d'une ressource dej& reserv6e par N 
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applications est mise dans une file d'attente, en attendant la liberation de 
la ressource par Tune des N applications. 

Selon un mode de realisation particulier, la mise en attente d'une 
application dans une file d'attente n'est effectuee que si cela est specifie 

5 par cette application. 

Selon un mode de realisation particulier, chaque application 
possede un profil correspondant a un niveau de priorite. 

Selon un mode de realisation particulier, un des niveaux de 
priority caracterise une application apte a etre directement commandee par 

10 un utilisateur. 

Selon un mode de realisation particulier, une application requiert 
le statut d'application primaire a une application primaire actuelle par un 
proced£ de negociation comportant I'etape d'acceptation ou de refus du 
remplacement par 1'application primaire actuelle. 

15 Selon un mode de realisation particulier, le proc£d£ de 

negociation est mis en oeuvre lorsque 1'application primaire possede le 
niveau de priorite caracterisant une application apte & etre commandee 
directement par un utilisateur et que le niveau de priorite de 1'application 
requerant le statut d'application primaire possede un niveau de priorite 

20 identique ou plus faible. 

Selon un mode de realisation particulier, une application requiert 
le statut d'application primaire a une application primaire actuelle par un 
procede de preemption comportant I'etape d 'abandon force dudit statut par 
1'application primaire actuelle. 

25 Selon un mode de realisation particulier, le procede de 

preemption est mis en oeuvre lorsque 1'application requerant le statut 
d'application primaire possede un niveau de priorite plus elev£ que le 
niveau de priorite de 1'application primaire actuelle. 

L'invention a aussi pour objet un appareil dans un reseau de 

30 communication domestique comportant au moins une ressource locale apte 
d etre reservee par d'autres appareils connectes au reseau et des moyens 
de connexion audit reseau, caracterise en ce qu'il comporte en outre un 
gestionnaire des ressources apte a memoriser des informations statiques 
et/ou dynamiques relatives a I'ensemble des ressources locales et des 

35 applications ayant reserve une ressource locale, lesdites informations 
identifiant pour chaque ressource reservee I'unique application possedant 
les droits d'acces les plus etendus a cette ressource. 
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D'autres caracteristiques et avantages de I'invention apparaitront 
a travers la description d'un exemple de realisation non limitatif illustre par 
les figures jointes parmi lesquelles 
5 - la figure 1 est un diagramme bloc d'un reseau d'appareils 

mettant en oeuvre le proced6 conforme & I'invention, 

- la figure 2 est un schema repr6sentant ('organisation logique 
d'un appareil de la figure 1. 

10 Sur les differentes figures, les memes elements portent des 

r£f£rences identiques. 

Le reseau de la figure 1 est constitue dans le present exemple de 
realisation d'un bus serie conforme au standard IEEE 1394 -1995. Ce bus, 
r6ferenc6 1, relie des appareils 2, 4, 5 et 6. On entend par 'appareil' un 

15 ensemble physiquement distinct reli6 au reseau. Chaque appareil peut 
comporter un ou plusieurs sous-appareils, tels que le sous-appareil 3. Ces 
sous-appareils peuvent etre des ressources, qui sont des fonctionnalites 
d'appareils Les ressources forment des modules logiciels ('software 
elements' en langue anglaise) au sens du document 'HAVi' mentionne plus 

20 loin. 

A titre d'exemple (voir figure 2), un appareil A est un decodeur 
de television numerique, tandis qu'un autre appareil, I'appareil B, est un 
magnetoscope. Le decodeur A possede deux ressources, d savoir un tuner 
12 et un demultiplexer 13. Le magnetoscope B possede Egalement deux 

25 ressources : un tuner 14 et la fonctionnalite d'enregistrement 15. Chacun 
des appareils A et B comporte une application (respectivement 18 et 19) 
qui est une interface utilisateur graphique, qui permet a un utilisateur de 
gerer directement les fonctionnalites de chaque appareil. L'interface 
utilisateur de I'appareil A permet selon le present exemple de realisation de 

30 gerer I'enregistrement, par un autre appareil du reseau, de programmes 
issus du demultiplexeur 13. Une ressource peut etre residente, c'est a dire 
presente des I'origine dans un appareil, mais peut egalement etre 
telecharg6e. 

Chaque appareil comporte egalement un registre (respectivement 
35 r6ferenc6 16, 17 pour chacun des appareil A et B). Le registre fait I'objet 
d'une demande de brevet francais au nom de la demanderesse, depos€e le 
23 avril 1998 et portant le numero 98051 10. II est d'autre part d6crit dans 



le document 'The HAVi Architecture - Specification of the Home 
Audio/Video interoperability (HAVi) Architecture' en date du 11 mai 1998 
en sa version 0.8 et mis d disposition du public depuis le 15 mai 1998 sur 
les sites Internet notamment des entreprises Sony, Philips, Toshiba, Sharp 
et Hitachi. On se r^ferera egalement S ces documents pour de plus amples 
renseignements sur les divers elements du r€seau, la pr6sente description 
se limitant aux elements n6cessaires pour Texplication de I'invention. 

Le registre d'un appareil (aussi appeI6 'registre local' pour cet 
appareil, par opposition d des 'registres distants* r^sidant dans d'autres 
appareils) participe a la gestion de I'ensemble des ressources de cet 
appareil. Pour cet effet, le registre comporte une table dans laquelle 
viennent s'enregistrer les autres ressources de I'appareil, en indiquant leurs 
attributs (type de la ressource, identificateur de la ressource dans le 
rgseau, ...). Lorsqu'un module logiciel doit communiquer avec un autre 
module logiciel local, il peut obtenir la liste de ces modules par 
I'intermediaire du registre local, qui poss&de une adresse locale connue. 
Lorsqu'un module logiciel doit communiquer avec un module logiciel distant 
d'un autre appareil, il peut obtenir I'adresse ('SEID') du module logiciel 
distant en passant par le registre local. Un module logiciel peut determiner 
une liste de modules correspondant h certains critferes de recherche, 
independamment de la localisation de ces modules, en transmettant une 
requete au registre local qui propage cette requete aux registres distants. 
La requete comporte sous forme de parametres les crit^res de selection 
des modules logiciels recherches, par exemple le type de module 
(afficheur, enregistreur, ...). 

A ce titre, les ressources d'un appareil s'enregistrent egalement 
au niveau du registre local, au meme titre que les autres modules logiciels. 
Un module teiecharge s'enregistre aupres du registre de I'appareil qui fait 
office de plate-forme d'execution de ce module. 

Une application peut etre de I'un des deux profils suivants : 
Utilisateur ou Machine. Le profil Utilisateur correspond a une application 
qui interagit directement avec I'utilisateur, comme par exemple I'interface 
utilisateur graphique 18 de I'appareil A. Le profil Machine correspond a une 
application qui n'est pas contrdlee directement par un utilisateur, mais qui 
met par exemple en oeuvre une action programmee. Une application peut 
controler une ressource. Une application peut egalement etre une ressource 
et 3 ce titre etre contrdlee par une autre application. Selon le present 



exemple de realisation, une application de profil Utilisateur aura une 
preponderance sur une application de profil Machine lorsqu'il s'agira de 
resoudre un conflit de reservation d'une ressource. On dira que le profil 
Utilisateur possede un niveau de priority plus elev6 que le profil Machine. 

Selon une variante de realisation, d'autres profils d'applications 
sont prevus: Arriere plan, Installation, S6curit6 et Syst6me, correspondant 
respectivement h des applications de faible priority occupies a des taches 
de fond (par exemple nettoyage de donn6es obsotetes), des applications 
utilises pendant I'installation et la configuration du r£seau, des 
applications informant I'utilisateur de certains ev6nements importants 
(alarmes de security par exemple), et des applications systeme (par 
exemple les registres et les gestionnaires de ressources), 

Une ressource poss&de un certain nombre de propri^tes : 

Une ressource peut etre de nature dite statique ou dynamique. 
Une ressource dynamique peut etre divis^e en plusieurs parties 
independantes, moyennant la specification de paramfetres ad^quats. 
Typiquement, la bande passante est une ressource dynamique: une 
application reservant une bande passante devra specifier la largeur de 
bande a reserver. Une ressource de nature statique est une ressource ne 
pouvant etre r6serv6e de cette maniere. 

Une ressource dynamique poss§dera un etat de reservation qui 
correspond a la quantite restante disponible. 

Une ressource statique peut etre dans un parmi trois etats de 
reservation, un etat dit disponible, un etat dit partage, et un 6tat dit 
verrouill6. Dans V6tat disponible, la ressource n'est controlee par aucune 
application. Dans I'etat partage, la ressource est controlee par au moins 
une application, mais d'autres applications peuvent n6anmoins utiliser la 
ressource, avec certaines restrictions concernant les commandes de 
controle admises pour ces autres applications. Dans T§tat verrouill6, la 
ressource est controlee par au moins une application et rejettera toute 
commande de controle en provenance d'une autre application. 

D 1 autre part, on associera a chaque ressource un descripteur, 
c'est £ dire une structure de donnees ou encore enregistrement, 
comportant des valeurs de variables identifiant les fonctionnalites de la 
ressource, ainsi qu'une adresse dans le reseau. Comme dejS mentionne, ce 
descripteur est enregistre au niveau du registre local. 



Selon le present exemple de realisation, le descripteur de 
ressource indique le domaine d'activite de la ressource (par exemple 
audio/video, chauffage, appareils menagers, ...), le type de la ressource, 
qui indique sa fonction (syntoniseur, decodeur, modem, ...), le niveau 
d'accessibilite (ressource 'locale', accessible uniquement par des 
applications residant dans le meme appareil, ou ressource 'publique', 
accessible 6galement par des applications executees sur des plates-formes 
autres que I'appareil dans lequel reside ('application publique). 

La gestion des ressources est basee sur un m6canisme de 
reservation. Une reservation est n^cessaire pour la mise en oeuvre de 
commandes de controle et plus generalement pour tout acces en ecriture 
changeant I'etat d'une ressource, Une reservation n'est gen6ralement pas 
necessaire pour un acces en lecture. Une fois une reservation accept£e, 
1'application devient une application cliente de la ressource: elle en a le 
controle, mais elle n'est pas n6cessairement la seule application a etre 
dans ce cas, d'ou la n^cessite d'un m6canisme de resolution de conflits 
d'acces d la ressource. 

Chaque appareil dispose d'un module logiciel appele 'gestionnaire 
des ressources*. Dans le r£seau de la figure 2, les gestionnaires des 
ressources des appareils A et B sont references respectivement 20 et 11. 
Ces modules collaborent avec les registres. Tandis que les registres 
maintiennent localement une liste des modules logiciels (ressources, 
applications, ...) disponibles, le gestionnaire des ressources gere les 
informations relatives d I'accessibilite et a I'etat de ces ressources. Selon le 
present exemple de realisation, un gestionnaire de ressources gere les 
ressources locales. Les informations maintenues par les registres sont 
relativement statiques, tandis que celles maintenues par les gestionnaires 
de ressources sont susceptibles d'evoluer rapidement, d'ou la separation 
des deux types de services. 

Selon le present exemple de realisation, un gestionnaire de 
ressources obtient la liste des ressources locales aupres du registre local. 
Les ressources non residentes sont ainsi facilement accessibles au 
gestionnaire de ressources. Par exemple, lorsqu'un module de controle de 
fonction CFCM' selon terminologie HAVi) est decharg6 a partir d'un 
appareil audio-vid^o de base ('BAV selon la terminologie HAVi), ce module 
de controle s'enregistre aupr&s du registre local de I'appareil lui servant de 




plate-forme d'execution, tel qu'un appareil audio-video & fonctionnalit6s 
completes CFAV). 

Les principes utilises pour le reservation sont les suivants : 

- avant de lancer une commande de controle d'une ressource, 
une application doit reserver cette ressource aupr&s du gestionnaire des 
ressources de I'appareil dans lequel reside la ressource, et 

- une application doit lib<§rer une ressource qu'elle n'utilise plus. 
Selon le present exemple de realisation, une application 

souhaitant effectuer une reservation determine I'adresse du gestionnaire 
des ressources de I'appareil dans lequel reside la ressource par 
I'intermediaire du registre de I'appareil dans lequel reside ('application. Une 
fois I'adresse obtenue, ('application peut contacter le gestionnaire des 
ressources en vue de s'informer de Tetat de la ressource. Le fait de passer 
par le gestionnaire des ressources au lieu de s'adresser directement & la 
ressource permet de maintenir les informations relatives a la disponibilite 
des ressources d'un appareil de manure centralisee au niveau de cet 
appareil. Par contre une fois la reservation obtenue, I'application ayant 
effectuee cette reservation obtient le controle de la ressource et adresse 
ses commandes de controle directement a la ressource. Le gestionnaire des 
ressources n'est contacte par la suite que pour indiquer que la ressource a 
ete liberee. 

Pour chaque ressource, le gestionnaire des ressources mainttent 
une structure de donn6es dite 'structure de contention 1 , qui contient les 
informations suivantes : 

(1) Informations statiques 

Ce type d'information n*a a priori pas vocation d evoluer. Ces 
informations sont chargees par le gestionnaire de ressources a partir des 
ressources. 

(a) Le mode de controle de la ressource 

Le mode de controle peut etre Tun des suivants: Transparent, 
Partageable, Exclusif. Dans le cas d'un controle partageable, on indiquera 
egalement le mecanisme de resolution de conflits d'accds partag6s: 
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Repartition des applications en application primaire et applications 
secondares, ou egalite de traitement pour toutes les applications. 

(b) Nombre maximum duplications supportees 
5 Ce champ est utilise en cas de mode partageable ou exclusif. La 

ressource indique le nombre maximal d'applications supportees 
simultan6ment, le minimum 6tant 1 . 



10 



25 



(2) Informations dynamiques 



(a) Informations relatives aux applications controlant la ressource 
Parmi les donnees memorises relatives & chaque application, on 

trouvera : 

- le profit de I'application (Utilisateur ou Machine), 

15 - le cas echeant, s'il s'agit d'une application primaire ou 

secondaire (voir ci-dessous), 

- des donnges dites privees, reservees 3 une utilisation non 
encore definie, 

- un champ texte comportant un descriptif du motif de la 
20 reservation (par exemple 'Enregistrement de la ChaTne Z f ). 

(b) Etat actuel de la ressource: Disponible, Partag6, Verrouille 

(c) Nombre d'applications controlant la ressource 

(d) Liste des applications controlant la ressource 



(e) Liste des applications en attente de pouvoir controler la 
ressource (par exemple parce que le nombre maximal d'applications pour 
30 cette ressource a et£ depasse). 

Les applications, comme les ressources, sont identifies par une 
adresse definie dans le document HAVi et portant le nom 'SEID\ 
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La ressource elle-meme doit egalement maintenir un minimum de 
donn6es relatives aux applications qui la controlent, en vue de la mise en 
oeuvre des m6canismes de preemption et de n6gociation. En cas de mise 




en oeuvre du mecanisme de repartition en application primaire et 
applications secondares, il faudra memoriser au moins I'identificateur de 
('application primaire. 

Dans le mode de controle Transparent, la ressource accepte un 
controle simultan<§ sans restriction de la part de plusieurs applications, sans 
faire de distinction entre les applications. 

Dans le mode Partageable, plusieurs applications peuvent 
contrdler en meme temps la ressource, mais cette dernifere mettra en 
oeuvre des proc£des de resolution de conflit d'acc§s et de partage de 
ressource si les commandes des applications risquent de conduire h un 
fonctionnement incorrect. 

Un exemple est celui du decodeur A de la figure 2. Le tuner de 
cet appareil est r£gle pour la reception d'un signal en provenance d'un 
transpondeur particulier, correspondant d un certain flux multiplex^. Dans 
ce flux, le demultiplexeur a la capacite de reperer les paquets 
correspondant & un service ou d un autre, et d'extraire ces paquets vers 
les applications clientes. En supposant qu'un flux donne vehicule une 
dizaine de services, des applications distinctes peuvent utiliser la ressource 
demultiplexeur pour acc£der 3 des services identiques ou differents. Le 
demultiplexeur fonctionne alors comme un serveur. Un conflit apparait 
lorsqu'une application veut changer de transpondeur: ceci implique que 
toute autre application perdra I'acces aux services transmis sur le 
transpondeur actuel. 

Selon Tinvention, le procede de resolution prefere d'un tel conflit 
est le suivant : les applications clientes d'une ressource sont classees en 
applications clientes primaires et secondaires. Une seule application peut 
etre une application primaire pour une ressource : c'est celle qui a reserve 
la ressource en premier. Toutes les autres applications sont des 
applications secondaires. La ressource accepte toutes les commandes en 
provenance de Tapplication primaire, mais peut n'accepter que certaines 
commandes, et ce de fa<?on Iimit6e, de la part des applications secondaires. 
Les commandes des applications secondaires ne sont prises en compte que 
dans la mesure ou elles n'entrent pas en conflit avec les commandes de 
I'application primaire. Dans Texemple du demultiplexeur donn6 plus haut, 
seule I'application primaire a la possibility de changer de transpondeur. Les 
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applications secondares ont simplement le droit de choisir un service sur le 
transpondeur actuel. 

Selon une variante de realisation, I'application primaire informe 
son utilisateur final (par exemple le telespectateur) des perturbations que 
son action peut entrainer. 

Selon le present exemple de realisation, les applications 
secondaires ont toutes des possibilites de commande identiques. On 
distingue deux procgdes: selon le premier proc6d£, une application ne peut 
perturber les commandes prec^demment transmises d la ressource par une 
autre application ('principe du respect mutuel'), tandis que selon le second 
proc£de, une application peut perturber une autre application. 

Dans tous les cas, ce qu'est une 'perturbation' d'une application 
secondaire par une autre depend de la nature de la ressource controlee et 
c'est cette derni&re qui devra trancher. Selon le present exemple de 
realisation, c'est le principe du respect mutuel qui est mis en oeuvre en ce 
qui concerne les conflits d'acc&s entre applications secondaires. 

Selon une variante de realisation, comme d£jd mentionne en 
relation avec ('application primaire, une application secondaire avertit, s'il y 
a lieu, son utilisateur final des restrictions imposees d son action. 

Selon une autre variante de realisation, le principe d'6galit6 de 
traitement des applications secondaires est applique a toutes les 
applications: il n'y a pas dans ce cas d'application primaire. 

Dans le mode Exclusif, la ressource ne pourra etre control6e que 
par une seule application a un moment donne. La ressource memorise au 
moins ridentit6.de cette application, ainsi que son niveau de prioriteltype 
Utilisateur ou Machine selon le present exemple de realisation). A titre 
d'exemple, on prendra la commande des m£canismes d'un magn£toscope, 
comme Tappareil B de la figure 2. Un conflit peut apparaltre si une 
application demande I'enregistrement d'une emission, tandis qu'une autre 
application demande un peu plus tard rejection du support 
d'enregistrement. Dans ce cas, la premiere application aura un controle 
exclusif. 



A titre d'exemple, la table 1 donne pour une ressource 
partageable des informations memorisees au niveau de chaque ressource : 
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Application 


Profil 


Accfes 


Dans queue 
d'attente 




I ITU IC A TCI ID 

U I ILloA I tun 
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in on 


A2 


MACHINE 


Secondaire 


Non 


A3 


UTILISATEUR 


Lecture 


Oui 



















Table 1 



Selon le type de ressource, le mode de controle peut differer 
pour diff6rentes commandes. Par exemple, seules les commandes qui 
changent l'6tat d'une ressource peuvent generer des conflits et justifier de 
ce fait un mode de controle exclusif ou partageable, tandis que toutes les 
autres commandes, acces en lecture, demandes d'ev^nements sont g£res 
selon le mode transparent. 

Pour r^server une ressource, une application transmet une 
commande correspondante au gestionnaire des ressources local d la 
ressource. Cette commande comporte en tant que parametres les 
informations relatives S Tapplication inscrites par la suite dans la structure 
de contention au niveau du gestionnaire des ressources. Aucune 
reservation n'est effectuee par une application pour une ressource en mode 
transparent. Selon le present exemple, une reservation est effectuee pour 
I'obtention immediate du controle d'une ressource. 

Selon T6tat actuel de la ressource, trois cas peuvent se 
presenter : 

- La reservation est acceptee et Tapplication devient Tapplication 
primaire ou une application secondaire. C'est le cas lorsque la ressource 
est initialement respectivement dans T6tat disponible ou partageable. 

- La reservation est rejetSe car la ressource est verrouill6e (par 
exemple parce que le nombre maximal d* applications a 6t6 atteint). 
L'application peut requerir, sous la forme d'un drapeau dans la commande 
de reservation, d'etre plac6e dans la queue d'attente de cette ressource, et 
d'obtenir une notification de la part du gestionnaire des ressources lorsqu'il 
lui aura automatiquement attribue un nouveau niveau d'acces (soit un 
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acces secondaire devenant primaire, soit une application dans la file 
d'attente devenant application secondaire ou primaire).. L'adresse de 
I'application est alors memorisee dans une pile de la structure de 
contention de la ressource appropride. 
5 - La mise en attente de I'application si son profil est tel qu'il lui 

permet de negocier le titre d'application primaire avec I'application primaire 
actuelle. Le m6canisme de negociation ou de preemption est, selon le 
present exemple, mis en oeuvre par le gestionnaire des ressources. 

10 Le gestionnaire des ressources transmet en retour vers 

I'application le resultat de la reservation. Si la reservation est accept£e, le 
message comporte £galement I' information selon laquelle ('application est 
primaire ou secondaire. 

15 Lorsque I'application a obtenu le contrdle de la ressource et a 

terming son action, elle transmet une commande de liberation de la 
ressource au gestionnaire des ressources. Ce dernier efface alors 
('application et les informations s'y rapportant de la structure de contention 
appropriee. 

20 C'est 6galement le cas pour une application en attente n'ayant 

plus besoin d'une ressource pour laquelle elle a tente d'effectuer une 
reservation dans le passe, elle doit liberer la ressource. 

Selon le present exemple de realisation, deux mecanismes sont 
25 pr£vus pour effectuer le remplacement d'une application primaire par une 
autre application : la preemption et la negociation. Le type de mecanisme 
est identifie dans la commande de reservation envoy6e par une application 
au gestionnaire des ressources. 

Lorsqu'une application souhaite negocier le statut d'application 
30 primaire avec I'actuelle application primaire, elle envoie un message en ce 
sens au gestionnaire des ressources, qui a son tour transmet un message a 
I'application primaire. Celle-ci peut soit accepter, soit refuser de ceder sa 
place. Une application de type Utilisateur peut par exemple transmettre la 
demande a I'utilisateur lui-meme. 
35 Une application peut egalement mettre en oeuvre le mecanisme 

de preemption pour s'approprier le statut d'application primaire. Dans ce 
cas, le gestionnaire des ressources v£rifie que cette application a bien la 
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priority pour faire cette requete, par rapport a la priorite de ('application 
primaire actuelle. S'il autorise la preemption, le gestionnaire des ressources 
envoie une commande de transfert, que I'application primaire a Tobligation 
d'accepter. Un temps donne est alors accorde d I'application primaire pour 
liberer la ressource. Si ce temps n'est pas respecte, le gestionnaire des 
ressources effectue le transfert d'office de la ressource. 

En liaison avec le m6canisme de repartition des applications 
clientes en application primaire et applications secondares, la resolution 
des conflits pour la position d'application primaire lors de la reservation 
r6pond aux regies suivantes, sachant que Ton se place dans le cas ou 
seuls les profils Utilisateur et Machine existent : 

(1) Une application de profil Utilisateur a toujours priority sur une 
application de profil Machine. 

(2) La premiere application r6servant une ressource partageable 
devient I'application primaire. Une application primaire peut interferer avec 
les commandes d'applications secondares. Une application secondaire ne 
peut interferer avec une commande de I'application primaire. 

(3) Une application de profil Utilisateur n'est jamais soumise au 
droit de preemption d'une autre application (Utilisateur ou Machine) sans 
phase de n£gociation. 

(4) Quand une application primaire libere une ressource, c'est 
I'application secondaire ayant le niveau de priorite le plus eleve qui devient 
application primaire. Dans le cas ou plusieurs applications secondares 
possedent ce niveau de priorite, c'est I'application la plus ancienne qui 
devient application primaire. Une application en attente prend alors la place 
de I'application secondaire. 

Quatre cas de conflit peuvent se presenter, selon le profil de 
I'application primaire et celui de I'application cherchant & effectuer une 
reservation (on supposera ici qu'il y a negociation chaque fois qu'au moins 
une des deux applications est de profil Utilisateur) : 

(a) L'application primaire a un profil Utilisateur et I'application 
requerant la reservation a un profil Machine : 

Dans ce cas, la ressource transmet un message d I'application 
Utilisateur pour verifier si ce dernier peut ceder la main. Si c'est le cas, 
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l'application de profil Machine devient I'application primaire. Sinon, 
('application Machine abandonne sa tentative. 

Un exemple correspondant £ ce cas est celui d'un telespectateur 
regardant un service diffuse sur un transpondeur A, tandis qu'un 
5 magnStoscope preprogramme doit enregistrer un service sur un 
transpondeur B, utilisant le meme tuner. 

(b) L'application primaire a un profil Machine et I'application 
requerant la reservation a un profil Utilisateur : 

10 Avant de remplacer I'application primaire Machine par 

I'application Utilisateur, le gestionnaire des ressources informe I'application 
Utilisateur des consequences potentielles de ce remplacement et lui 
demande une confirmation du remplacement, en lui donnant la possibility 
de laisser I'application primaire finir sa tache. 

15 Un exemple correspondant & ce cas est celui ou un 

magn6toscope enregistre un service d'un transpondeur A f tandis qu'un 
telespectateur souhaite regarder un service sur un transpondeur B, utilisant 
le meme tuner. Le telespectateur est alors averti que I'enregistrement en 
cours devra etre arrete s'il confirme sa decision. 

20 

(c) L'application primaire a un profil Utilisateur et I'application 
requerant la reservation a egalement un profil Utilisateur : 

Dans ce cas, l'application primaire deciders de garder ou 
d'abandonner son niveau primaire: le principe est le meme que dans le cas 
25 (a). 

Un exemple correspondant a ce cas est celui ou un premier 
telespectateur regarde un service sur un premier transpondeur (dont il a le 
controle par I' intermediate d'une application primaire), tandis qu'un second 
telespectateur souhaite regarder un autre service d'un autre transpondeur, 
30 en utilisant le meme tuner. Le second telespectateur ne pourra r^gler le 
tuner sur la frequence du nouveau transpondeur qu'avec I'accord du 
premier telespectateur. 

(d) L'application primaire a un profil Machine et l'application 
35 requerant la reservation a un egalement un profil Machine : 
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Etant donne que selon ie present exemple, toutes les applications 
de profil Machine ont la meme priorite, I'application primaire termine sa 
tache sans etre remplacee. 

De maniere plus generale, quand plus de deux profits existent, le 
comportement du systeme est decrit par la table 2. Dans la variante de 
realisation comportant plus de deux profits mentionn6e ci-dessus, les 
profits S£curite et Systeme ont d titre d'exemple des niveaux de priorite 
plus Aleves que le profil Utilisateur. II n'y a jamais de preemption d'une 
application de profil utilisateur par une application de niveau de s£curit£ 
identique ou inferieur sans phase de negociation. Cependant, selon 
I'exemple decrit par la table 2, il n'y a pas de negociation lorsque 
('application primaire a un profil Utilisateur, mats que I'application 
cherchant a obtenir le controle poss&de un niveau de priority strictement 
superieur. 



Profil/Priorite 
de 

I'application 
orimaire 


Priority de 
1* application 
reauerant la 
reservation 


Mecanisme lance 
par le qestionnaire 
des ressources 


Nouvelle 
application primaire 


Utilisateur 


Priorite 
superieure 


Preemption 


Application 

requ£rant 

reservation 


Utilisateur 


Priorite 
identique ou 
inferieure 


Negociation 


Application 
primaire actuelle ou 
Application 
requerant 
reservation 


Priorite 

differente 

d'Utilisateur 


Priorite 
superieure 


Preemption 


Application 

requerant 

reservation 


Priority 

differente 

d'Utilisateur 


Priorite 
identique ou 
inferieure 


Requete rejet6e ou 
mise en attente 


Application 
primaire actuelle 



Table 2 
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Revendications 

1. Proceed de gestion de priorites d'accds d'applications § des 
ressources d'appareils connects par un reseau de communication, 
caracteris6 en ce que ledit proced6 comporte les Stapes : 

- d'attribution d'un niveau primaire de droits d'accfes a une 
application effectuant la reservation d'une ressource, 

- d'attribution d'un niveau secondare de droits d'acces d 
d'autres applications effectuant une reservation de ladite ressource, les 
droits d'acces du niveau secondaire etant tels qu'ils n'interferent pas avec 
les droits d'acces du niveau primaire. 

2. ProcedS selon la revendication 1, caracterise en ce qu'une 
ressource admet simultan6ment des reservations par au moins N 
applications, avec N sup£rieur ou egal a 1 . 

3. ProcedS selon la revendication 2, caracteris6 en ce qu'une 
application effectuant une tentative de reservation d'une ressource deja 
r£servee par N applications est mise dans une file d'attente, en attendant la 
liberation de la ressource par Tune des N applications. 

4. Proc6de selon Tune des revendications prec6dentes, 
caracterise en ce que chaque application possede le profit correspondant h 
un niveau de priorite. 

5. Procede selon la revendication 4, caracterise en ce qu'un des 
niveaux de priorite caracterise une application apte a etre directement 
commandee par un utilisateur. 

6. Procede selon Tune des revendications precedentes, 
caracterise en ce qu'une application requiert le statut d'application primaire 
a une application primaire actuelle par un procede de negociation 
comportant I'etape d'acceptation ou de refus du remplacement par 
Tapplication primaire actuelle. 

7. Procede selon la revendication 6 # caracteris£ en ce que le 
procede de negociation est mis en oeuvre lorsque ('application primaire 
possede le niveau de priorite caracterisant une application apte a etre 
commandee directement par un utilisateur et que le niveau de priorite de 
I'application requerant le statut d'application primaire possede un niveau de 
priorite identique ou plus faible. 
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8. Proc6de selon Tune des revendications precedentes, 
caracterise en ce qu'une application requiert le statut d'application primaire 
a une application primaire actuelle par un precede de preemption 
comportant I'etape d'abandon force dudit statut par I" application primaire 
actuelle. 

9. Procede selon la revendication 8, caracterise en ce que le 
procede de preemption est mis en oeuvre lorsque Tapplication requerant le 
statut d'application primaire possede un niveau de priority plus eieve que le 
niveau de priorite de ('application primaire actuelle. 

10. Procede selon la revendication 3, caracterise en ce que la 
mise en attente d'une application dans une file d'attente n'est effectuee 
que si cela est specifie par cette application. 

11. Appareil dans un reseau de communication domestique 
comportant au moins une ressource locale apte 3 etre r6serv6e par d'autres 
appareils connectes au reseau et des moyens de connexion audit reseau, 
caracterise en ce qu'il comporte en outre un gestionnaire des ressources 
(11; 20) apte a rnemoriser des informations statiques et/ou dynamiques 
relatives a I'ensemble des ressources locales et des applications ayant 
reserve une ressource locale, lesdites informations identifiant pour chaque 
ressource r6servee I'unique application possedant les droits d'acces les 
plus etendus a cette ressource. 
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